Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/inet/ietf/rdisc/rdisc-minutes-90may.txt

Text File | 1993-02-17 | 11.0 KB | 298 lines

CURRENT_MEETING_REPORT_

Reported by Steve Deering/Stanford

Minutes:

This was the third meeting of the Router Discovery Working Group.

Steve Deering started by apologizing for not having produced a draft
specification of the proposed router discovery protocol in time for this
meeting, and promised to do so before the July IETF meeting.

He then reviewed the current proposal, for the sake of newcomers.

The router discovery protocol uses a pair of new ICMP messages:


   o Router Advertisement messages, which are periodically multicast by
     routers.
   o Router Solicitation messages, which may be multicast by hosts at
     start-up time only, to solicit immediate Router Advertisements
     instead of waiting for the periodic ones.


(These were formerly called ``Router Report'' and ``Router Query''
messages, respectively.)

Advertisements are sent to the ``all-hosts'' IP multicast address, and
solicitations are sent to the ``all-routers'' IP multicast address.
Hosts and/or routers may be configured to use IP broadcast addresses
instead, though this is discouraged.  The router discovery protocol is
not applicable to networks that do not support either IP multicast or IP
broadcast.



                                   1






The format of the Router Advertisement message is as follows:



  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |           Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Reserved    |     Count     |         Holding Time          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Router Address                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Preference Level                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Router Address                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Preference Level                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                              .                              |
  |                              .                              |
  |                              .                              |



Type                identifies this as an ICMP Router Advertisement.

Checksum            standard ICMP checksum.

Code and Reserved   zero.

Count               number of (Router Address, Preference Level) pairs
                    included in the message.

Holding Time        number of seconds that hosts should consider the
                    information in this message to be valid.

Router Address      one of the sending router's IP addresses on the
                    physical network on which this message is sent.

Preference Level    preferability of the preceding router address as a
                    default router address, relative to other router
                    addresses belonging to the same IP subnet.



The usual case in which a router has more than one address on a single
physical network is when that network is supporting more than one IP
subnet.  A receiving host is expected to ignore those (Router Address,
Preference Level) pairs that do not belong to the same IP subnet as the

                                   2






host.  (This implies that a host must know its own IP address and subnet
mask before it may use the information in a Router Advertisement
message.)



                                   3






The format of the Router Solicitation message is as follows:



  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |           Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Reserved                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Type                identifies this as an ICMP Router Solicitation.

Checksum            standard ICMP checksum.

Code and Reserved   zero.



The group then discussed a number of topics that had been raised on the
mailing list since the previous meeting.


   o Preference Level field
     Deering tried again to convince the group that the Preference Level
     field was unnecessary and undesirable, and again he failed.  It was
     agreed that the field shall be present in the Router Advertisement
     messages, if for no other reason than that the Host Requirements
     document requires a preference level to be associated with each
     default router (even though it does not require hosts to do
     anything with it).
     Deering then proposed that the Preference Level be encoded as a
     signed, 32-bit, twos-complement integer, such that a higher value
     means more preferable.  A router that is not configured with a
     specific preference level (or that does not compute its own
     preference level, based on routing information), will advertise a
     level of 0.  The minimum level (80000000 hex) is reserved to
     indicate routers that must not be used as default routers (i.e.,
     that may be used only for specific destinations, of which the hosts
     have been informed by ICMP Redirect or static configuration).
     Greg Satz had proposed that a router's preference level be derived
     from that router's metric for its ``default'' route, rather than
     from manual configuration.  After some discussion of the merits and
     weaknesses of that approach, it was agreed that it would be allowed
     but not required by the router discovery specification.  It was
     noted that a routing metric will normally have to be converted to a
     preference level, rather than being used directly, since for most
     routing metrics, smaller values mean more preferable.

                                   4






  No objections were raised to Deering's proposed encoding for the
  Preference Level field.
o multicast vs.  unicast replies to Solicitations
o dallying
  Two unresolved issues were:  should Advertisements sent in response
  to Solicitations be multicast or unicast, and should randomized
  delays be required before Solicitations and/or before responding
  Advertisements?  Some people felt that dallying before
  Solicitations was important to prevent massive collisions when a
  LANful of hosts all boot at once, for example, after power is
  switched on (in a classroom, say) or is restored after a power
  failure.  After much debate, it was agreed that hosts should dally
  for a short, random interval (between 0 and 1 seconds was
  suggested) before sending a Solicitation.  If a host receives an
  Advertisement while dallying, it should refrain from sending a
  Solicitation.
  The optimal router behavior in response to a Solicitation is not at
  all clear -- a case was made for dallying or not, and for either
  unicast or multicast responses.  Therefore, this will be left to
  the implementors' discretion for now, with a suggestion that the
  behavior be configurable.  The group would welcome any analysis,
  simulation results, or reports of field experience that might favor
  a particular behavior.
o periodic advertising rate
  Another outstanding issue was how often the periodic, unsolicited
  Advertisements should be sent.  The choice depends on whether or
  not the advertisements are being used for black-hole detection, in
  addition to simple router discovery.  For black-hole detection, the
  advertising rate must be high enough to allow router failures to be
  detected before transport connections fail (an interval of 10
  seconds is the value used for this purpose in the ISO ES-IS
  protocol).  If the advertisements are only used for router
  discovery, a much longer interval (10 minutes, say) would be
  adequate -- in this case the periodic advertisements serve only for
  recovery from the situation in which hosts and routers boot up on
  different sides of a subnet partition, which is later healed.
  In the absence of agreement on how black-hole detection should be
  done, the advertising interval must be configurable.  The initial
  version of the document will suggest a default interval of 10
  minutes.  Subsequent decisions on black-hole detection may cause a
  smaller default value to be recommended.
o black-hole detection
  Once the router discovery specification has been agreed upon, it
  has been suggested that this working group might turn its attention
  to the black-hole detection problem.  A general discussion of the
  problems and possible solutions ensued, with no agreements being
  reached.  (It was pretty much a rehash of previous discussions on
  the group mailing list; an archive of those messages is available
  for the interested reader.)



                                5






Action Items


   o Deering to generate a draft Router Discovery specification before
     the July IETF meeting.
   o Experimental implementations of the proposed protocol to be
     developed and deployed -- no promises, but Andrew Cherenson and
     John Veizades both offered to help (presumably for Unix and for the
     Macintosh OS, respectively), as soon as Deering gets the
     specification done.  Greg Satz has previously offered the source
     code for his BSD Unix implementation of cisco's Gateway Discovery
     Protocol (GDP) as one possible starting point.


Next Meeting

The Router Discovery Working Group will next meet in Vancouver, at the
July/August IETF meeting.



                                   6






ATTENDEES


    Pat Barron               [e-mail]
    Fred Bohle               [e-mail]
    Steven Bruniges
    David Burdelski          [e-mail]
    Duane Butler             [e-mail]
    John Cavanaugh           [e-mail]
    Andrew Cherenson         [e-mail]
    Noel Chiappa             [e-mail]
    Steve Deering            [e-mail]
    Dave Forster
    Richard Fox              sytek![e-mail]
    Karen Frisa              [e-mail]
    Steve Hubert             [e-mail]
    Van Jacobson             [e-mail]
    Stev Knowles             [e-mail]
    Yoni Malachi             [e-mail]
    Keith McCloghrie         sytek![e-mail]
    Leo J. McLauglin III     [e-mail]
    Jeff Mogul               [e-mail]
    John Moy                 [e-mail]
    Mike Patton              [e-mail]
    Drew Perkins             [e-mail]
    Stephanie Price          cmcvax![e-mail]
    Michael Reilly           [e-mail]
    Greg Staz                [e-mail]
    Tim Seaver               [e-mail]
    Frank Slaughter          [e-mail]
    Richard Smith            [e-mail]
    Brad Strand              [e-mail]
    Cal Thixton              [e-mail]
    John Veizades            [e-mail]
    Jonathan Wenocur         [e-mail]



                                   7